Commodore Free 7/Commodore_Free_Issue_07_2007_Commodore_Computer_Club.d64/t.minigames comp

Text File | 2023-02-26 | 7KB | 256 lines

uMini Games Competition
http://www.minigamecomp.org.uk/

FAQ

Q: What's this about a "moderator"?

A moderator is responsible to verify
that the program meets submission/size
requirements, that it works in an
emulator, & so on. If you would like to
see a platform represented (or would
like to volunteer! Yeah!) eMail the
organizer and we'll work something out!

Q: Can moderators submit entries?

Absolutely. As long as a submission
meets the requirements, it may compete.

Q: I'm writing a game for multiple
platforms. How should it be submitted?

The general idea is one game, one vote.
Therefore, please pick a version that
you'd like to compete, & place the rest
in the EXTRAS area.

Q: I'm concerned about 24/7 voting.
Will people vote consistently over
time? What if someone updates an
entry? As a competition, should we even
be able to download games early, let
alone vote?

The votesheet is just a piece of paper
for keeping notes. You still have to
submit it, at the end of the contest,
when you're satisfied with it. If some-
one updates an entry -- well, after you
play that updated entry, you can update
your votesheet. Finally, as to being
able to download, I believe that down-
loading games during the contest
stimulates interest in the contest, & I
don't believe it has caused any issues
the last two years. And, of course,
there are just too many entries. So, I
suggest trying the votesheet this way,
and if we find it causes problems we
can do something different next year.

Q: Please clarify the starting with
RUN rule.

The general idea is that the game
should be started in the standard way
for the platform, whatever that may be.
On a Commodore machine & the speccy,
it's LOAD followed by RUN, on a CP/M or
MS-DOS machine you'd just type the name
of the executable on the command line.

So no loaders (they count toward the
size), the user shouldn't have to type
any special commands to start (like
SYSxxxx on a C=), & so on. Autostarting
executables are OK. This makes life
much, much easier on those trying to
run (& judge) the programs.

Q: My platform has a big header & is at
a disadvantage.

Actually, the header losses are all
about the same. More broadly, every
platform has some dead weight in the
executable, including differences in
sprite sizes, bitmaps, screen clearing,
CPU architectures, system resources,
etc.

The competition will never be "fair".
The computers are so different in their
capabilities that it's impossible to
create a perfectly level playfield.
The computers have different strengths,
& weaknesses. Be creative, use nasty
tricks, & make as good a game as you
can in 1K or 4k.

Q: But...

It's a nightmare. Consider the CPC
AMSDOS header -- 128 bytes. Most of
that, however, is empty, & programmers
routinely store code & data in it.
Checking that this header doesn't
contain code/data is a truly awful
prospect; by contrast, including
headers gives around a 10-byte penalty
-- just like pretty much every other
platform. Let's say you take away the
header restriction. Commodore 64 &
Speccy files do not autoboot, so they
need a BASIC program to start with
RUN.

Now you need to either not count the
BASIC header, or else remove the RUN
restriction. Now life is tougher on
users, so maybe external loaders
should now be allowed -- can we put a
title or other information in the
loader? Then, of course, C64 programs
also store a two-byte load address in
the file, so maybe that shouldn't be
counted. And in the first contest MV
stored the score in the BASIC line
number, so maybe that should be counted
after all. But if you want to get
really technical, then the file
structure includes... But then this
obscure computer has... But compared to
this other computer it... And remember,
this makes life much, much easier on
those trying to run (and judge!) the
programs, especially on unfamiliar
platforms.

Q: But...

It's like representative democracy:
it's not that it's the best system,
it's that it's the least worst system.

Q: How do I determine file size?

Commodore 64: Extract from a .d64 if
necessary, then ls -l (unix) or dir
(dos) -- i.e. memory plus two bytes.
Speccy: the .TAP file can be at most 25
bytes more than the size limit imposed
by the category (basically it's the
memory used: the 17-byte header, data
block byte, & checksum do not count,
but the BASIC header etc. does). CPC:
Use CAT. NES and 2600 cartridges: The
.NES file header is NOT counted. The
6502 interrupt vectors are. Otherwise,
all unused bytes must be set to zero.
Apple 2: Files should be submitted on a
DOS3.3 .DSK image. The file size is the
256 times the number of sectors minus
one. For other platforms check the
forum or ask the moderator. If there is
no moderator, the organizer.

Q: I'd like to make an Atari 2600 VCS
game, but the minimum cartridge size
is 2K.

Use the last 1024/4096 bytes of the
cartridge, fill the rest with 0s, &
don't use the 0s as data (or code, but
I don't know what a lot of BRK would be
good for). (And we'll find you a
moderator, if you really do want to
submit a 2600 game!).

Q: Can I submit previously written
stuff?

Yes, as long as you've written
everything yourself. You are for
obvious reasons not allowed to use
other people's material without their
express permission. This includes
graphics and tunes (i.e. ripping is
verboten). Standard things like
compressors & assemblers are fine of
course.

Rules

All entries are welcome, the 3 size
categories will be held seperate from
one another, though they can be
submitted at any time up until the
closing dates.

The file size is the size of code+data
as is natural for your system - i.e.
emulator only data is not included.

The following is this years sizes

1kbyte (1024 bytes max)
2kbyte (2048 bytes max)
4kbyte (4096 bytes max)

Screenshots should be of the actual
game, there is no point in 'doctoring'
the picture to make game look better,
people will play them.

Forum discussions that may influence
votes are to be avoided.

Keep the games clean of porn, profanity
etc.

The games must be submitted using a
common emulator format.

Any excess fileformat space should be
filled with 0's - i.e. the NES's
minimum INES fileformat size is 16k
so for 1k, 15k is filled with 0's.

The Data+code must be in one continous
block, not seperated in different
sections of the ROM/Bin.

It is your responsibility to submit a
game screenshot and description for
the webpage.

Entries should use standard hardware/
software features of their system & not
require extra hardware/software
features, though something like RAM
expansion is allowed along as it is
stated in the game instructions.

Compression may be used, as long as
the decompressor is stored within the
game.

No FLASH/Web page based games are
allowed in this competition. Last year
we have had an entry which was done
in Flash, which we could not accept.
Any games like this will not be
evaluated.

Most important of them all. Have loads
of fun programming your game for this
compo.

1k category, this will run until 31st
July 2007, 10pm GMT time the 2k size
category will run until August 31st,
10pm GMT the 4k size will run until
September 30th, 10pm GMT